1. Field of the Invention
The invention relates in general to a computer field, and more particularly to a hardware control method and apparatus for multitasking drivers under a user mode.
2. Description of the Related Art
In a Unix system such as Linux, programs including device drivers can be operated under two modes—a user mode and a kernel mode. System resources provided in the two modes are quite different.
A program operating under the user mode has restricted access to only a part of system sources, and is incapable of directly accessing kernel data structures to directly interact with kernel programs. This is one of the primary benefits of running a driver in user mode; there is improved stability, since a user mode device driver cannot crash the system by overwriting kernel memory.
Taking a 32-bit central processing unit (CPU) for example, a program operating under the kernel mode can execute any CPU command, access any location of a 4 G memory space, and directly access desired core data structures or programs.
A driver is a storage area that is system file formatted and carries a drive code. In an overall control link, a driver is a middle link located between a main controller and a motor. A main function of a driver is to receive a signal from the main controller, process the signal and transmit the processed signal to the motor and a sensor associated with the motor, and feed an operation condition of the motor back to the main controller.
To share hardware devices and data under a multitasking environment, a mainstream Linux driver operates under a kernel mode. However, several drawbacks are incurred.
First of all, it is difficult to evade from General Public License (GPL) restrictions, since the driver is included in the Linux kernel. Once being enveloped by the GPL, it is mandatory that the driver make its source code public, and such requirement is quite unacceptable in commercial applications which rely on keeping proprietary information secret.
Secondly, as applications need to frequently enter and exit the kernel mode, extensive system loadings may be incurred by certain hardware devices with complicated functionalities such as a graphic processing display, such that overall system performance is degraded.
Thirdly, when access congestion occurs in one program of a driver operating under the kernel mode, congestion in operations of the entire system often results even if the access congestion is caused by only one faulty process. In contrast, under the user mode, when access congestion occurs in one program of a driver, congestion only results in a process utilizing the program instead of affecting the entire system and other processes.
Moreover, under the kernel mode, adjustments to hardware devices cannot be made easily, and such a problem is even more severe in situations where registers of hardware devices are frequently accessed.
Some drivers based on the user mode are currently available. However, these drivers can only be applied to simple hardware devices, and still fall short in providing applications with secured random access to hardware devices in a multitasking environment.